The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In packet-switched networks, routers are used to route data packets between various network elements. Routers need to be configured to provide various tasks. For example, a router may be configured to route streaming video on a particular interface from 8:00 am to 5:00 pm and then may be configured to provide a different capability on the same interface during the rest of the day. Furthermore, a router may be configured to process packets in different ways, or to provide different capabilities from one day to the next.
One approach to configuring routers is to establish a communication session, such as a telnet session, from a configuration management application residing on a network management station to a particular router across a network, and transmit commands, such as command line interface commands (CLI commands), to the router. However, this approach has disadvantages. One disadvantage is the performance cost. The configuration management application has to send a command, receive a response, and determine the nature of the response for each command during a configuration change, and perform rollbacks, if necessary, in response to configuration errors. Therefore, the performance of the configuration management application suffers as the number of commands increases.
A second approach to configuring routers is to download configuration files, which typically comprise a large number of CLI commands, to a router using Trivial File Transfer Protocol (TFTP) using the command line interface (referred to hereinafter as the TFTP using CLI approach). A third approach is for a configuration management application to transfer a configuration file by setting values in Management Information Base (MIB) objects of the router using Simple Network Management Protocol (SNMP) messages (referred to hereinafter as the SNMP approach). In the third approach, once the values for the MIB objects are set, configuration files are downloaded using TFTP. However, these approaches also have numerous disadvantages.
One disadvantage of the TFTP using CLI approach is the inability to determine, in the event of a configuration failure, which command in the configuration file failed. Consequently, the configuration management application does not have enough information to take appropriate action, such as performing rollbacks or determining whether to copy a particular configuration file, which resulted in errors, to other routers.
A disadvantage of the SNMP approach is that, while it is possible to determine the status of the configuration file transfer to the device, no means is provided to determine the results of executing the configuration commands in the device. Thus, while the TFTP approach and SNMP approach provide performance improvement, configuration management applications cannot provide functions such as “rollback configuration changes,” because the applications cannot determine the results of configuration changes.
Based on the foregoing, there is a clear need for determining the nature of a configuration failure in a network device that uses SNMP based TFTP or CLI based TFTP configuration transfers, while minimizing performance costs.
There is a particular need for an approach that enables a configuration management application to determine whether errors occurred during a configuration change when the changes are made using SNMP and MIB instrumentation.